home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group92c.txt / 000009_icon-group-sender _Mon Oct 5 14:41:51 1992.msg < prev    next >
Internet Message Format  |  1993-01-04  |  2KB
  1. Received: by cheltenham.cs.arizona.edu; Mon, 5 Oct 1992 15:44:59 MST
  2. Date: Mon, 5 Oct 92 14:41:51 -0700
  3. From: wgg@cs.UCSD.EDU (William Griswold)
  4. Message-Id: <9210052141.AA13973@gremlin>
  5. To: goer@midway.uchicago.edu, icon-group@cs.arizona.edu, keil@apollo.hp.com
  6. Subject: Re: storing objects
  7. Status: R
  8. Errors-To: icon-group-errors@cs.arizona.edu
  9.  
  10. >From: keil@apollo.hp.com
  11. >Date: Mon, 5 Oct 1992 12:16:43 -0400
  12. >To: "Richard L. Goerwitz" <goer@midway.uchicago.edu>,
  13. >        icon-group@cs.arizona.edu
  14. >Subject: Re: storing objects
  15. >
  16. >>Let's say that I have a large table that I want to store and recreate
  17. >>at run-time in a program.  What is the best way of doing this?  What
  18. >>I mean by "best" is primarily "fastest," and not "smallest."
  19. >>Any better ideas?
  20. >>-Richard
  21. >
  22. > What is large? 1k, 10k, 100k elements?
  23. > With the old scheme of non-expandable tables, I found that increasing
  24. > the initial table size had a big effect for tables of over a thousand
  25. > elements. I'm not sure where the breakover point is for the newer
  26. > expandable table mechanism, but I suspect that if you make the initial
  27. > table size at least as big as, if not twice that size of, your table,
  28. > that things will go faster. At one point, back in the version sevens,
  29. > I added a second parameter to table [table(x,size)] to set the initial
  30. > size of the tablas needed. This seemed more elegant that just always using
  31. > a larger table. On the other hand, with virtual memory systems,
  32. > You may not care if the initial table size is always 10k elememts (if you
  33. > decide to just staticly increase the initial allocation size.)
  34. >
  35. >-Mark
  36.  
  37. The new table mechanism actually expands the number of ``slots'' or ``buckets''
  38. in the table as elements are added.  This provides good table performance
  39. through about 2^16 (64k) elements for 32 bit machines, less on others.
  40. It is not hard to tweak the implementation to substantially increase that
  41. threshold for little cost in space (i.e., you can double the threshold for
  42. about 8 bytes in space for each table, I believe).
  43.  
  44. The new mechanism also takes less space for small tables, reducing memory
  45. requirements for applications that use many small tables.
  46.  
  47.                         Bill Griswold
  48.                         UCSD
  49.                         wgg@cs.ucsd.edu
  50.